It should probably be left up to a linter to make sure control statements are where they're supposed to be. Honestly think we should do what the stdlib parser does and not have a distinction between statements and expressions, though don't know how we'll handle its edge cases n stuff. Not something to worry about for this PR.

Essentially, tree sitter would parse as much as possible and leave form errors to a different tool (no def/class/etc in def, control statements in right place, etc). Thoughts?

(I don't have any experience in writting a parser / grammar but) I think it's better to go with the approach of "parse as much as you can be sure of", rather than possibly overestimating
it is MUCH more annoying to see syntax highlighting be wrong, than inprecise

I think this parser could accept weird forms that are invalid to the compiler, at least now since anything is better than nothing.

Then when it starts to be usable as syntax highlighter we could improve it until it start to be useful as a syntax checker.

BTW what you meant by your comment was: reject returnat top level, right?

I think we could do this later, I can file a bug about it if this PR gets accepted as is.

Yes, return / next / break are only allowed in certain contexts (not top-level, only inside methods and blocks) and are implemented (essentially) the same from the parsers perspective

for sure this return rule must be improved, hehere, but one step at a time.

return return return

parsed as

source_file [0, 0] - [1, 0]
  return [0, 0] - [0, 13]
    identifier [0, 7] - [0, 13]
  return [0, 14] - [0, 20]